This disclosure relates to use of a charging system to account for service provided by a network element in a service provider network. For example, this disclosure describes exemplary embodiments of a method for using a charging system to account for service provided by a network element in a service provider network and exemplary embodiments of apparatus associated therewith. A charging control function (CCF) server in the charging system maintains load information records for CCF servers in the charging system so that when it is too busy to respond to an accounting request (ACR) from a network element (i.e., overload condition), it can provide the network element with at least one alternate CCF in an accounting answer (ACA) to the network element which may be used in a failover process by the network element to re-send the ACR to the suggested alternate CCF. This disclosure describes the related communications of status messages between the CCF servers in the charging system. The related exchange of ACAs in response to ACRs is also disclosed herein. The various embodiments are described in relation to accounting for service provided by a network element of an internet protocol (IP) multimedia subsystem (IMS) network during an IMS session. However, the methods and apparatus described herein may be use to account for services provided in other types of networks and for other types of communication sessions.
By way of background, RFC 3588 describes the base Diameter protocol that lays the foundation of charging in IMS, long term evolution (LTE), and other domains for both online as well as offline charging for IMS sessions. While using the Diameter protocol on the Rf reference point, a network element (NE) that implements a charging trigger function (CTF) communicates service charges by sending ACRs toward the charging collection function (CCF). The CCF responds by sending ACAs back to the CTF. This provides reliability on a per message basis.
In certain cases, the sending entities can overwhelm the CCF. For example, when the network experiences a high traffic volume beyond its engineered capacity, the CCF may become overloaded. Also, when the network experiences outage of one or more servers that implement the CCF functionality, the CCF may become degraded. A combination of both of these conditions could easily result from attempts to compensate for overloaded or degraded conditions.
Each CCF server provides an inherent load management scheme. As provided in RFC 3588, the load management scheme allows a CCF to respond to CTFs by sending an indication of overload in a Result-Code parameter of the ACA response. For the overload condition, the CCF responds with the Result-Code set to 3004 in the ACA message, the Result-Code signifies a “DIAMETER_TOO_BUSY” condition at the CCF. Upon receipt of this 3004 Result-Code, the CTF should attempt to send the ACR message to an alternate peer using a failover procedure in accordance with RFC 3588.
However, this gives rise to a direct and at least two dependent issues. The direct issue is that the indication in the Result-Code does not state or suggest one or more alternate peers that can be tried by the CTF for reliable transmission of the ACR. This means the CTF has to find an alternate peer “blindly” and may stumble upon the same overload situation at the alternate peer as well. The derived issue is that without this indication, the CCF server nodes may end up producing several ‘Incomplete CDRs’ for the same IMS session and thereby cause additional issues for the downstream mediation by the billing system. Secondly, the CTF may prolong the recovery of an overloaded or nearly overloaded CCF server if it is chosen as an alternate peer. This may be detrimental from an overall network sanity perspective and may have a rippling effect from the CCF in which the condition originated.
The existing behavior, as allowed in the RFC 3588, is for the CTF to seek an alternate peer that would allow a reliable reception of the ACR. For example, a first overload indication may result in the following messaging:
CTF→ACR→CCF1
CTF←ACA (3004)←CCF1 (overload)
A second try with an alternate peer CCF may result in the following messaging:
CTF→ACR→CCF2
CTF←ACA←CCF2 (success!) or
CTF←ACA (3004)←CCF2 (overload!)
So, if CCF2 can receive the ACR, then the problem is somewhat mitigated. However, in a network, it is likely that when one CCF is experiencing overload, other CCF servers are similarly experiencing overload or near overload conditions. Therefore, it would not be unusual that CCF2 also provides an overload indication. Under these circumstances, the CTF would have to search for a different alternate peer that can receive the accounting message.
A tertiary (i.e., third) try with another alternate peer CCF may result in the following messaging:
CTF→ACR→CCF3
CTF←ACA←CCF3 (success!) or
CTF←ACA (3004)←CCF3 (overload!)
As before, CCF3 may likewise be overloaded and may refuse the ACR.
Additionally, an initial success indication from an alternate peer is no guarantee that this CCF has the spare capacity to handle the remaining session. For, it may itself be on the verge of going into an overload situation, and may refuse to handle subsequent messages after having accepted the first message:
CTF→ACR→CCF3
CTF←ACA←CCF3 (success!)
. . .
CTF→ACR→CCF3
CTF←ACA (3004)←CCF3 (overload!)
The example given above is a simplified example. In a network deploying approximately tens of servers providing the CCF functionality, the process of selecting an alternate peer in case of overload can be cumbersome and prone to trial and error.
Thus, it can be seen that the “blind” search can lead to increased traffic in the network. This mechanism also gives rise to each CCF that successfully receives at least one ACR from part of the IMS session having to create an “Incomplete” CDR. Under these circumstances, the complete IMS session accounting is not available at any server and “Incomplete” CDRs from two or more servers must be reconciled downstream to determine the total billing amount attributed to the CTF for the IMS session. Downstream, it becomes a chore for the billing mediation to collapse several incomplete CDRs into a single IMS session-specific CDR to bill the subscriber for the service provided by the CTF.
The drawbacks of the current standards are summarized as follows: i) the search for an alternate peer is blind and the first alternate peer sought may not have the processing bandwidth to accommodate the ACR, ii) additional network traffic is generated via the blind search, iii) incomplete CDRs are created at all the CCFs successfully receiving at least one ACR from the CTF during the IMS session, iv) additional processing is incurred at all CCFs touched by the CTF during the IMS session, and v) additional processing is incurred at the back-end billing mediation to merge the incomplete CDRs for a full IMS session into a complete CDR. Of these, the biggest offender is the blind search for an alternate peer. Clearly, an intelligent search for an alternate peer CCF with sufficient left-over processing capacity that reduces the number of incomplete CDRs associated with the CTFs for the IMS session is desirable over current techniques.
With reference to FIG. 1, a CTF is first connected to CCF1. After accepting a Start ACR or at least one Interim ACR, an ACR (1) is responded to with an error code in the Result-Code AVP (i.e., AVP Code 268) of the ACA. The CTF then connects to alternate peer CCF2, which is also experiencing high load conditions. After accepting one or more ACRs from the CTF, CCF2 provides a similar overload indication, forcing the CTF to seek a connection to alternate peer CCF3. In this exemplary scenario, CCF3 can accommodate the ACR processing and does not return an overload indication. Under this scenario, all three CCFs generate an Incomplete CDR (4, 5 and 6) that is communicated to billing mediation (BM).
Based on the foregoing, techniques that enable a CCF server in a charging system to identify or recommend alternate CCF servers when it is experiencing an overload condition is desirable. Additionally, it is desirable that information regarding these alternate CCF servers be incorporated in the ACA to a network element that has sent an ACR to a CCF server currently experiencing an overload condition.